The Content section is used to enter and preview the message content, to define different format versions, and to configure the link tracking options.
The features and options available from the Content section are described below.
When you're finished with the Content section, click next at the bottom of the screen to move to the Review section, or click the review tab you need to move back to the Setup section, click previous at the bottom of the screen, or click the setup tab.
tab
aging supports two methods for entering email messaging content:
Advanced Editor: Using a full-featured HTML code editor, enter your message content. You can define different format versions and use other Messaging assets (such as Content Blocks or Opt-Out Messages) to build out the content. The Advanced Editor is the default method for entering message content, and is displayed if you don't have the Content Designer enabled in your account. For more information, please see the Advanced Editor Help topic.
Content Designer: The Content Designer provides a graphical, user-friendly interface for building email content. The Content Designer is primarily intended to be used by marketers who prefer not to work with HTML. The Content Designer is an optional feature that must be enabled in your account; if you don't have this feature enabled, the platform will display the Advanced Editor instead. For more information, please see the Content Designer Help topic.
The Preview window allows you to view a rendering of your message content as it will appear to your recipients. The Preview window also provides additional features as described below.
To see a preview of your message content:
Note: When using LiveContent content in your email campaign, an impression is always recorded on the content when previewed (or the URL requested in proofing) and will require your LiveContent credit.
|
Personalization Fields allow you to populate message content with values pulled from your database. To test the Personalization Fields in your email content:
|
If you have Dynamic Blocks in your message content, different recipients will receive different variations of the message, based on the rules set up within the Dynamic Block. To test the Dynamic Content variants in your email content:
Note: If you have Dynamic Content in your header, the header fields are listed separately than the Dynamic Content fields in the message content. |
Proofing refers to the process of testing a marketing campaign by sending out sample messages to a special set of recipients. Proofing is intended to verify that your marketing message appears the way you intend, and that any dynamic content within the message is being generated and populated correctly. From within the Preview window, you can send proofs. Note: You can also send proofs from the review section of the Campaign screen (see Review for more details on this section). The proof method available from within the Preview window provides nearly the same functionality, but with one notable difference -- the Preview window method lets you enter custom Personalization values. Conversely, the review section method of proofing will use values pulled from a random Test Member in the EDP database. To send a proof from the Preview window:
|
By default, an Email Campaign will contain two format versions -- HTML and Plain Text. The Plain Text version is needed to accommodate recipients who only accept text emails, either because of a configuration setting or limitation of their email client. If you don't create a Plain Text version, the system will automatically create one for you.
The platform allows you to further customize the content beyond just HTML and Plain Text, in order to display different content in certain environments, if needed.
For example, you could optionally set up an "iPhone" format version that contains specific creative content to display if an iPhone user opens up the email. This content can be different from the main HTML email content and use smaller graphics and less text to fit the width of the smaller screen size better. If you don't create an iPhone specific version, iPhone users would receive the original HTML email message, so it’s not mandatory to create an iPhone version.
We recommend that you create two additional format versions -- "Web" and "Viral."
The Web version is a web hosted version of the email message. This format is useful if users are having trouble viewing the email in their email client, as it provides an alternate way to view it properly in a web browser. Typically, you would want to remove the "View as Web" link from the Web version.
The Viral version (also known as the "Send to a Friend" or "Forward a Friend" message), is a version of the email that is forwarded from the original recipient to the friend. This Viral message might have different content and even have an extra link to allow the friend to subscribe himself or herself. You should also delete the opt-out link from the Viral version to prevent the friend from inadvertently unsubscribing the original recipient (the one who forwarded the message). Since Messaging requires the presence of an opt-out merge code, simply insert a blank opt-out block into the Viral version.
Messaging allows you to define HTML, Plain Text, and AMP format versions of your email message content in order to accommodate the different devices and applications used by consumers to view your message. For more details, please see Format Versions. Within the Content section, each version of your message is displayed as a separate tab. Simply select a tab to see the content for that version. Most of the format versions in Messaging are actually groups containing multiple sub-options. For example, the "HTML" version contains options for:
By default, all of these options are contained within the parent HTML version, meaning that the same HTML content will be used for all of those different contexts. Optionally, you can pull one or more of those options out of the parent version, and create a new, separate format version. This process is referred to as "promoting" a format option into a new group. See "Promote a Format Option" below for more details. Plain TextBy default, the platform will create an HTML version of your message content. You can (and typically should) also create a Plain Text version. Plain Text versions are generally required by ISPs for deliverability purposes. If you don't create a Plain Text version, the platform will automatically create one upon message deployment. This system-generated Plain Text version is created based on the HTML version. To create a new Plain Text format version:
AMPYou can optionally also create an AMP (Accelerated Mobile Pages) format version. AMP supports more sophisticated, interactive email message content. For example, AMP allows the recipient to fill out a form, browse inventory, or respond to a comment, all from within the email message, without having to navigate to a web page. If a consumer has an email application that's not configured to view AMP messages, they can still see the HTML (or Plain Text) version of your message. To create a new AMP format version:
|
To delete a format version of your message content:
|
The HTML and Plain Text format versions in Messaging are actually groups containing multiple sub-options. For more details, please see Format Versions. Optionally, you can pull one or more of those options out of the parent version, and create a new, separate format version. This process is referred to as "promoting" a format option into a new group. For example, if you need the "Mobile" version of your HTML content to be different than the "Email" HTML content, you could promote "Mobile" to its own format version. Within the user interface, the system displays a new tab on the Content Editor with the label "HTML 2 - Mobile." Note: The platform allows you to promote as many format versions, and create as many new groups, as you want. Continuing the above example, you could add the "iPhone" option into the "HTML 2 - Mobile" group. Or you could further promote "iPhone" into its own version, and the system would create a new tab named "HTML 3 - iPhone." Conversely, format options can be "demoted," which moves them back into their previous format version group. To promote a format option into its own version:
To demote a format option:
|
Messaging allows you to define HTML and Plain Text format versions of your email message content in order to accommodate the different devices and applications used by consumers to view your message. If a consumer has an email application that's not configured to view HTML messages, they can still see the Plain Text version of your message. For more details, please see Format Versions. The format versions in Messaging are actually groups containing multiple sub-options. Optionally, you can disable these options so that they're not used within your Campaign. To disable a format option:
To enable a previously disabled format option:
Note: Optionally, you can pull one or more of these options out of the parent version, and create a new, separate format version. This process is referred to as "promoting" a format option into a new group. See "Promote / Demote a Format Option" above for more details. |
Campaigns can be configured with specific link tracking details, such as which links to track, what to call those links, and what append codes or Tags to use. The platform will parse your Campaign message content to attempt to identify links within the content.
To configure Link Tracking in your Campaign:
In addition to improving report readability, the use of friendly names allows you to keep links distinct from each other, even if they go to the same destination URL. For example, you might have two links to your company's home page within your message content -- one within the header and one within the footer. By giving these two links different friendly names ("Home Header" and "Home Footer" for example), you can track these two links separately. The system provides several different ways to assign a friendly name for a link:
<a data-link-name="Cheetah Digital home" href="http://www.cheetahdigital.com">Cheetah Digital Home Page</a>
{@Cheetah Digital home|http://www.cheetahdigital.com@} Note: The link name parameter can be used only in HTML or Text format versions. Also, links contained within Looping Blocks will not support the link name parameter. If the friendly name has not previously been defined through the Link Library, or within the Content Editor, then the system will use a default name, such as "Link 01" followed by the URL. You can manually override this default name, and enter a new friendly name in the "Link Tracking" list. When you launch the Campaign, the system will automatically add this link / friendly name to the Link Library. Note: In order for the platform to recognize the link friendly name, the link name and URL (or href tag) must be located in the same content source. For example, if you have links contained within Content Blocks used within a Campaign, the Content Block would need to contain both the link name parameter and the URL or href tag.
|
A "deep link" is any link that directs a user past the home page of a website or mobile app to content inside of it. For example, you might want to deep link directly to a specific product page instead of to your home page. Deep linking is supported through the use of "Universal Links on IOS, or App Links on Android" which can direct your mobile user to either a website or a mobile app. Universal Links and App Links are standard web links (for example: http://www.cheetahdigital.com) that point to both a web page and a piece of content inside your branded app. When this link is opened on a mobile device, the device's operating system checks to see if any installed app is registered for your domain. If so, the app is launched immediately without ever loading the web page, and the user is directed to a specific page inside of the app. If the user doesn't have your app installed, the web URL is loaded in the device's web browser, as usual. Deep link functionality must be enabled in your account in order to be available, and your web domain (or optionally multiple domains) must be registered to allow your app to handle the URLs. In addition, you must provide your "Universal Links Files for IOS, or App Links files for Android" to Marigold, to be hosted within the platform. This file authenticates your domain with your app, meaning that links from this domain can be opened in your app. When configuring deep links in your Campaign, you typically need to provide a deep link "tag." This tag value tells the mobile device what page to open in the app. A tag value is needed if your app doesn't have the ability to parse Engage+'s link tracking (Engage+ obfuscates the URL when the platform tracks link), or if the recipient is opening the link on a phone without cell service or network access, so the URL can't be parsed. A deep link tag is appended to the end of the URL using the parameter "dl." The syntax of the deep link tag depends on your app, and what it expects to see. The tag value could be a full URL, or it could just be part of the URL, such as "/products/1398," for example. Your app developers should be able to tell you want you need to provide as a deep link tag value. To configure deep links in your Campaign:
|
To enable Link Tracking in your Campaign:
In tracked links, the Proxy ID parameter (pi) is ON by default and is essential to Marigold’s Machine Learning models, including STO. The option “Remove Proxy ID Tracking” suppresses this pi parameter and stops the campaign from contributing to all ML models and calculations. We recommend not activating this option unless absolutely necessary. This option is only for the very small amount of marketers who had trouble accommodating this parameter in their redirects. |
To test that the URLs in your links are all valid:
Note: If you get any "Unable to Verify" results, check that the text of your URL is correct, and that the target link will be working at the time of the Campaign delivery. You can test the target link by clicking the eyeball icon next to the URL; the system opens the target URL in a separate browser window.
|
Tags are an organizational tool that can be used to classify links into custom groups for reporting and tracking purposes. Campaign reports will show click responses rolled up by Tag value, allowing you to analyze the combined performance of a group of links. For example, you could assign all of the links in your navigation menu with the Tag "navigation." This Tag could then be used to view click activity for all links with the "navigation" Tag. Also, Tags can be used as Filter criteria when building an Audience for a future Campaign, so you could select all subscribers who clicked on a "navigation" link, for example. Link tags are a Campaign-level setting; these tags can't be defined on the Link Library screen, but instead only on the Campaign screen. To assign a Tag to a link:
|
Append Codes are an optional feature used for link tracking purposes through your own tracking system, or through third-party vendors like Omniture and Google Analytics. The Append Codes you assign will be appended to each tracked link in an Email Campaign. If you use Looping Blocks in your Campaign content, the platform will automatically apply Append Codes to all hard-coded links found within the Looping Block. A hard-coded link is any link starting with "<a href="https://", or <a href="http://". For example: <a href="https://{$page_url}"> <a href="https://cheetahdigital.com"> <a href="http://cheetahdigital.com{$page_url}"> Append Codes can be manually entered at the Campaign level, or they can be defined as repeatable Append Code sets. Append Code sets can also be defined as "Default," meaning the platform will automatically assign them to every Email Campaign. For more information on how to create and manage Append Code sets, please see the Append Codes Help topic. To assign Append Codes to your Campaign:
Sample Append CodeSample Append Code Append Codes consist of two parts -- a key and the value (thus, they are often referred to as a Key Value Pair). The Append Codes are written as a query string, and are separated from the URL by means of a question mark (?). If assigning multiple Append Codes, each Key Value Pair must be separated by an ampersand (&). The following example URL contains two Append Codes. The first one is named "src" and has a value of "eml." The second one is named "email" and has a value of "myemail@cheetahdigital.com." www.cheetahdigital.com?src=eml&email=myemail@cheetahdigital.com Append Code values can be static values, as in the above example, or they can be dynamically populated by pulling values from a field in your database. For example, if you wanted to populate the "email" parameter with the value found in the "email_address" field in your database, you would use a Merge Symbol within the Key Value Pair: www.cheetahdigital.com?src=eml&email={(email_address)} Anchor tags (#), or "fragment identifiers," can optionally be added to a URL to identify a subordinate portion of a web page. If using both a query string and a fragment identifier, the query string portion should come first. For example: www.cheetahdigital.com?src=eml&email=myemail@cheetahdigital.com#test
Note: Within the list of assigned Append Code sets, the manually-entered Append Codes appear as the item labelled "Append Codes." You can rearrange this item, just like an Append Code set; however, you can't remove this item. If you don't want to assign any manually-entered Append Codes to this Campaign, simply leave the "Append Codes" field blank. |